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Abstract 

This  paper  suggests  a  reference  model  for  PHM  processes 
that  aids  the  customer  of  PHM  in  developing  a  business  case 
for  adopting  PHM  in  his  or  her  supply  chain.  Various  PHM 
systems  have  been  envisioned  and  developed  in  order  to 
produce  a  prognosis  of  system  or  component  behavior  by 
collecting  physical  data  from  some  section  of  a  system, 
analyzing  it  and  reporting  the  results  to  the  entity  that 
benefits  from  it,  notably  the  supply  chain  that  manages  the 
components  and  receives  the  resulting  cost  benefit  from 
PHM.  All  these  systems  have  varying  configurations  that 
involve  the  collection  of  different  types  of  data  in  different 
ways,  the  analysis  of  varying  types  of  physical  behavior  and 
have  different  types  of  customers  (different  supply  chain 
configurations).  The  customer  needs  to  include  the  cost  and 
complexity  of  the  PHM  system  in  his  or  her  business  model 
but  has  no  formal  standard  to  determine  bounds  on  the 
complexity  of  the  PHM  system.  Just  as  there  are  reference 
stacks  for  service-oriented  architectures,  this  paper  proposes 
a  functional  stack  for  PHM  that  can  become  a  reference 
architecture  for  developing  or  purchasing  a  PHM  system  for 
an  organization.  The  stack  of  PHM  services  ranges  from  the 
data  acquisition  layer  through  analysis  functions  to  supply 
chain  decision  support  services. 

1.  Introduction 

There  are  numerous  treatments  of  the  structure  of  systems 
that  are  designed  to  provide  prognostics  and  health 
maintenance  (PHM)  (examples  of  these  systems  is  described 
in  Section  2).  They  all  deal  with  sampling  data  at  some  rate 
and  analyzing  it  for  some  characteristic  that  indicates  that 
there  is  a  pending  system  or  component  failure.  Sometimes 
the  designs  are  focused  on  a  particular  aspect  of  PHM,  e.g.  a 
particular  type  of  data  analysis,  but  they  all  begin  to  take  on 
similar  structures.  In  addition,  regardless  of  the  system,  the 
common  goal  of  the  various  functions  in  PHM  is  to  improve 
lifecycle  costs  in  the  supply  chain  or  alternatively,  to 
provide  readiness  and  availability  of  components  in  the 
supply  chain.  In  this  effort,  it  is  the  business  case  analysis 
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(BCA)  that  determines  the  effectiveness  of  PHM  system 
functions.  The  BCA  provides  requirements  for  the  design 
of  PHM  system  functions. 

A  stack  architecture  would  stratify  these  PHM  functions 
into  domains  that  are  orthogonal  in  their  system 
responsibilities.  That  is,  they  involve  disjoint  sets  of 
activities  that  produce  data  that  is  consumed  by  the  function 
above  it.  In  this  regard,  the  activities  in  each  layer  are 
opaque  to  the  other  layers.  This  paper  presents  a  stack  of 
functions  that  can  be  used  as  a  reference  stack  architecture 
for  PHM.  The  reference  architecture  is  driven  by  the 
analysis  of  various  existing  PHM  architectures  and  the 
extraction  of  a  commonality  from  them. 

Stacks  of  functions  or  responsibilities  are  used  in  systems 
architecture  to  partition  the  subsequent  design  activities  and 
enable  reuse  of  functions.  They  enable  the  development  of 
clean  interfaces  between  system  functions  in  that  a  layer 
only  consumes  the  information  from  adjacent  layers.  The 
reference  stack  presented  here  can  enhance  the 
implementation  of  the  BCA  requirements  because  it  exposes 
PHM  functions  in  a  way  that  makes  them  transparent  to 
PHM  system  architecture  development.  There  is  less  of  a 
chance  that  the  PHM  system  would  incur  an  unforeseen  cost 
due  to  unnecessary  development.  Supply  chain  stakeholders 
can  agree  on  the  functional  structure  of  the  system  and 
understand  the  level  of  effort  that  is  required  to  develop  the 
system. 

Section  2  surveys  a  few  PHM  systems  that  have  been 
described  in  the  literature  in  order  to  extract  some  common 
functionality  for  the  discussion  in  Section  3  that  organizes 
PHM  functions  into  the  reference  stack. 

Clearly  there  are  far  more  systems  than  are  discussed  in 
Section  2,  but  the  structures  are  similar.  The  intent  is  to 
develop  a  motivation  for  the  common  stack  of  system 
functions  in  Section  3.  For  detailed  descriptions  of  these 
systems  and  others,  the  reader  is  referred  to  the  references 
and  literature.  A  goal  of  this  paper  is  to  be  able  to  employ 
its  results  in  evaluating  as  well  as  designing  PHM  systems. 
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2.  Background 

This  section  reviews  some  previous  PHM  architectures  in 
order  to  extract  some  commonality  to  support  the  discussion 
of  the  reference  stack  architecture  that  is  appears  in  Section 

3.  There  have  been  several  approaches  to  developing  PHM 
systems.  They  all  involve  the  collection  of  data  (generally 
data  from  sensors)  from  a  platform  system  that  is  managed, 
along  with  its  assembled  components,  by  the  supply  chain. 
The  collected  data  is  analyzed  by  either  a  data  driven 
approach,  which  performs  statistical  analysis  of  the  data  or  a 
model  driven  approach,  which  develops  a  physical  model  in 
order  to  trace  the  behavior  of  the  data  to  specific 
components  on  the  platform  (Analysis  is  discussed  in 
Section  3.2).  Both  techniques  can  be  employed  in  an 
analysis.  The  results  of  the  analysis  are  then  transmitted  to 
consumers  such  as  the  decision  process  in  the  supply  chain. 
The  results  of  analysis  support  maintenance  and  component 
management  in  the  supply  chain. 

Overall,  the  results  of  PHM  produce  several  benefits  to  the 
supply  chain:  there  is  a  cost  and  availability  benefit  to 
lifecycle  systems  management  that  is  driven  by  the  acquired 
capability  to  defer  maintenance  optimally  and  therefore 
lower  maintenance  costs.  In  addition  there  are  benefits  that 
are  orthogonal  to  life  cycle  cost  such  as  improved 
component  and  system  reliability  and  safety. 

The  following  sections  review  some  of  these  PHM 
architectures. 

2.1.  PHM  Architecture  Driven  by  a  Systems  Engineering 
Approach 

Begin  (2012)  describes  a  general  architecture  that  is  derived 
by  applying  systems  engineering  principles  to  PHM.  This 
work  develops  a  methodology  for  producing  a  “solution- 
neutral”  PHM  architecture.  A  functional  decomposition  is 
given  in  Figure  1.  The  various  components  that  are 
associated  with  PHM  are  given  but  there  is  no  connectivity 
to  the  supply  chain  decision-making  services  to  complete 
the  requirements  of  the  supply  chain  for  lifecycle  cost 
management. 

Nevertheless,  the  simple  functional  structure  in  Figure  1 
forms  a  basis  for  formally  defining  what  a  PHM  system  is. 
Data  acquisition  is  fundamental  and  provides,  generally, 
time  series  data  that  the  other  layers  consume.  Diagnostics 
obviously  looks  for  failed  or  faulted  components  while  the 
more  difficult  to  achieve  prognostics  might  sit  on  top  of 
diagnostics  and  use  diagnostic  services  to  produce  a 
prediction  of  remaining  useful  life  of  a  component.  Finally, 
health  management  provides  overall  condition  maintenance 
data  to  the  supply  chain,  which  is  not  shown.  Testability  is 
a  function  that  can  be  a  logical  activity  that  is  absorbed  into 
each  of  the  functions. 


Figure  1.  Notional  PHM  architecture  (Begin,  2012). 


2.2.  Boeing  IHVM  Reference  Architecture 

Boeing  developed  a  comprehensive  integrated  vehicle 
health  management  reference  architecture  (Keller,  Wiegand, 
Swearingen,  Reisig,  Black,  Gillis  &  Vandernoot,  2001)  that 
is  shown  in  Figure  2. 


Onboard  IVHM  -  Operational 
Maintenance  Program  (OMP) 


Figure  2.  The  Boeing  integrated  vehicle  health  management 
architecture  (Keller,  et.  al.  (2001)). 

PHM  functions  are  distributed  from  the  vehicle  to  analysis 
activities  that  are  off-platform  and  a  data  warehouse.  Their 
partitioning  is  dependent  on  the  characteristics  of  the 
infrastructure  such  as  network  bandwidth. 

A  reference  stack  of  PHM  functions  is  given  in  Figure  3 
where  PHM  data  flow  from  sensors  at  the  bottom  through 
signal  processing  of  the  data,  monitoring  of  component 
condition,  developing  a  health  assessment  of  the  platform 
and  then  a  prognostic  estimate  of  component  lifetime  which 
is  a  remaining  useful  component  life.  Decision  Support  is 
the  recipient  of  the  analysis  results  that  uses  them  for 
lifecycle  management  in  the  supply  chain.  The  presentation 
layer  represents  peer-to-peer  communication  with 
stakeholders  in  the  supply  chain. 

All  of  the  PHM  functions  are  present  in  the  stack  in  Figure  3 
and  the  reference  stack  that  is  developed  in  this  paper  is 
similar  to  it  and  will  be  discussed  in  Section  3. 
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Figure  3.  Stack  of  functions  in  the  Boeing  reference  IHVM 
architecture  (Keller,  et.  al.,  2001). 

2.3.  Distributed  Prognostic  System  Architecture 

Expanding  the  diagrams  in  Figure  1  and  Figure  2,  the 
prognostic  results  of  the  PHM  analysis  function  can  be 
transmitted  to  the  decision  support  function  via  publish  and 
subscribe  services.  In  the  architecture  in  Roemer,  Byington, 
Kacprzynski  and  Vachtsevanos  (2006)  that  is  shown  in 
Figure  4,  data  flows  to  logistics  decision  support  at  the  top. 
Analysis  algorithms  are  specified  to  be  at  the  lower  level  in 
the  stack  that  is  located  at  the  subsystem  that  is  under 
observation.  A  reasoner  hierarchy  isolates  fault  regions 
with  reasoners  placed  at  the  subsystem  in  addition  to  the 
platform  so  the  analysis  function  can  be  distributed 
vertically  in  the  stack. 

The  functions  in  Figure  4  begin  to  look  layered  and  the 
publish-subscribe  mechanism  with  a  data  pipe  for  big  data 
defines  clean  interfaces  that  support  both  the  sharing  of  data 
and  the  opacity  of  the  functions  that  produce  the  data. 
Section  3  will  organize  these  functions  into  a  reference  stack 
of  PHM  architectural  functions. 


Figure  4.  The  distributed  prognostic  system  architecture  in 
Roemer,  et.  al.  (2006). 


2.4.  Distributed  PHM  Algorithms 


Saha,  Shaha  and  Groebe  (2009)  give  a  more  tightly  coupled 
distributed  PHM  architecture.  In  this  architecture,  shown  in 
Figure  5,  the  analysis  functions  are  distributed  onto  sensors 
with  computational  elements  (CE).  The  Central  Server 
assists  in  analysis  if  there  is  insufficient  remote 
computational  capability,  for  example  in  the  particle  filter 
algorithm  that  creates  the  RUL  probability  distribution. 


Figure  5.  A  distributed  PHM  architecture  of  sensors  with 
computational  elements  that  perform  analysis  (Saha,  Saha  & 
Groebe.  2009). 

Were  this  architecture  to  be  fit  into  a  stack  structure,  the 
analysis  function  is  still  layered  above  data  acquisition  even 
though  it  is  distributed.  As  will  be  seen  in  Section  3  the 
stack  is  devoid  of  deployment  strategy  because  it  is  a  logical 
functional  specification. 
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Again,  absent  in  this  architecture  is  the  connection  to  the 
supply  chain  support  services  in  the  enterprise  that  is  in 
Figure  4.  In  developing  a  BCA  for  such  an  architecture,  the 
supply  chain  connectivity  needs  to  be  considered  because  it 
is  the  recipient  of  the  benefit.  Section  3.3  discusses  the 
value  of  this  connection  in  relation  to  the  BCA.  Clearly, 
this  system  could  be  integrated  into  the  supply  chain  with  a 
services  interface  because  of  its  computational  capability. 
The  connectivity  at  the  level  of  the  CE  would  be  less 
complex  (have  a  simpler  data  transfer)  due  to  limitations  to 
computation. 

In  organizing  this  architecture  in  a  functional  stack,  the 
communications  functions  to/from  the  CE  can  be  specified 
as  another  interface  to  the  analysis  function  from  the  data 
acquisition  function.  This  will  be  developed  in  Section  3. 

2.5.  F/A-18  Inflight  Engine  Condition  Monitoring 
Architecture 

Hall,  Leary,  Lapierre,  Hess  and  Bladen  (2001)  present  a 
PHM  architecture  for  the  F/A-18,  known  as  the  Inflight 
Engine  Condition  Monitoring  System  (IECMS),  shown  in 
Figure  6.  The  IECMS  is  an  end-to-end  system  in  which  the 
sensor  data  is  retrieved  from  components  on  the  aircraft  in 
the  upper  left  of  Figure  6  and  transferred  to  analysis 
functions  at  the  ground  station  that  provide  results  to  the 
pilot,  maintainer  and  maintenance  control  on  the  right. 

The  data  collection  architecture  on  board  the  aircraft  is 
further  specified,  producing  a  stack  of  responsibilities  from 
the  component  that  is  sensed  to  the  maintenance 
stakeholders.  The  functions  in  this  design  also  support  the 
reference  architecture  that  is  developed  in  Section  3. 


Figure  6.  The  F/A-18  Aviation  Maintenance  Environment 
(AME)  Ground  Station  (Hall,  Leary,  Lapierre,  Hess,  & 
Bladen,  2001). 

In  Figure  6  the  data  store  is  the  central  part  of  the 
architecture.  The  data  types  are  described  in  the  data 
transfers  between  the  nodes,  for  example  the  fault  data  from 


the  aircraft  and  the  maintenance  data  from  the  data  store. 
The  pilot  and  maintainer  on  the  right  form  the  decision 
support  services  (at  least  part  of  them)  in  the  supply  chain. 
This  architecture  conforms  to  the  stack  in  Figure  3. 

2.6.  PHM  Architecture  for  Defense 

Butcher  (2000)  presents  an  architecture  that  describes  a 
condition-based  maintenance  system  for  the  Department  of 
Defense.  It  functionally  decomposes  into  many  of  the 
components  that  are  in  the  architectures  that  have  been 
presented  so  far.  Figure  7  shows  the  architecture  diagram. 

CBM  System  Block  Diagram 


(On  System) _ (At  System) _ (Off  System) 

O-Levet  I  ntermecSate  /  Depot 

Weapon  System  Maintenance  Level  Maintenance 


Figure  7.  The  condition-based  maintenance  architecture  for 
the  DoD  in  Butcher  (2000). 


The  architecture  in  Figure  7  defines  three  domains,  On 
System,  At  System  and  Off  System.  The  functions  in  the 
stack  in  Figure  3,  Sensor  and  Control  Data  and  Signal 
Processing  are  located  on-system.  The  At-System  domain 
is  meant  to  be  the  data  collection  function  with  the  Portable 
Maintenance  Aid  shown  in  the  figure.  In  the  operational 
environment,  connectivity  can  be  reduced,  hence  there  is 
reliance  on  a  physical  means  of  data  transfer  off  the 
platform;  computing  capabilities  on  platform  can  be  reduced 
hence  analysis  functions  are  moved  to  the  right.  However, 
Butcher  does  discuss  the  richer  on-system  computing 
environment  of  the  Joint  Strike  Fighter  that  is  diagrammed 
here  in  Section  2.8  and  conforms  to  this  architecture. 
Supply  chain  decision  support  services  are  in  the  Off 
System  domain  on  the  right  with  the  data  store.  This 
diagram  conforms  to  the  stack  of  functions  in  Figure  3. 

A  similar  architecture  is  developed  in  Section  3.3.2. 

2.7.  Condition  Monitoring  Framework 

Another  way  to  partition  a  PHM  architecture  is  by  its 
ontological  elements.  There  is  a  description  and  data 
hierarchy  of  what  PHM  functions  do,  and  Emmanouilidis, 
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Fumagalli,  Jantunen,  Pistofidis,  Macchi  and  Garetti  (2010) 
develop  an  architecture  by  including  the  knowledge  base 
involved  with  condition-based  monitoring,  notably, 
“Physical  Assets,  Networking,  Knowledge  Management, 
Computational  Models  and  Usage  of  Information  & 
Operational  Technology”.  The  result  is  Table  1. 


Table  1.  A  condition  monitoring  relational  data  table 
(Emmanouilidis,  et.al.,  2013). 


Physical 

Assets 

Networking 

rr/OT 

Maintenance  Knowledge 

Computational 

Model 

System 

MANWMAN. 
LAN 'WLAN. 
3&4G 

ERP.Snvurs 

System  class 

State 

Sub-system 

LANWLAN 

ERP.MES. 
CMMS,  SFCS, 

Desktop  Server 

Sub-system  class 

Sub-system- level 

Novelty  Detection 
Diagnostics 

Prognostics 

Unit 

LAN, WLAN 
PANWPAN 
Gateways 

Sensor:, 

Actuators. 

Co  ■  hoDi  i 
DAQ.RFID, 

PDA 

Unit 

Unit-level 

Fault  modes 

Fault  nwkinKnr. 

Fault  seventy 

Fault  articalrty 

Asset  relations 

Fault  symptoms 

Fault  features 

Measurement  characteristics 

Collective  Models, 

Single  Node  Models 
Unit-level 

Novelty  Detection 
Diagnostics 

Fault 

Prognostics 

Component 

Serial  Bus 
PANWPAN 

Sensor:, 

Actuators, 

Controllers 

DAQ.RFID. 

PDA 

Component  class 

Fault  modes 

Fault  trwhanirm-. 

Fault  seventy 

Fault  cnUcaltfy 

Asset  relations 

Fault  symptoms 

Fault  features 

Measurement  characteristics 

Single  Node  Models 

Novelty  Detection 
Diagnostics 

Fault  modelling 

Prognostics 

In  Table  1  there  is  a  stack  of  physical  assets  in  the  left 
column,  but  these  are  quite  different  from  the  PHM  assets 
that  were  described  in  the  architectures  in  the  previous 
sections,  notably  the  stack  in  Figure  3. 

The  functions  across  the  top  of  Table  llook  like  they  could 
be  organized  into  a  stack  that  is  similar  to  the  one  in  Figure 
3,  but  there  are  knowledge  areas  and  models.  What  is  useful 
in  Table  1  is  the  compilation  of  the  semantic  terms  for 
condition-based  maintenance.  The  Maintenance  Knowledge 
column  organizes  the  fault  information,  which  is  critical  to 
condition-based  maintenance.  The  Computational  Model 
column  has  analysis  areas.  The  networking  column  has  the 
connectivity  units.  It  is  as  if  this  architecture  could  reside 
on  top  of  the  other  architectures  that  are  described  in  this 
section.  As  such  it  is  a  semantic  architecture  that  could 
reside  in  a  communications  stack. 

This  paper  develops  a  stack  of  PHM  functions  in  Section  3. 
It  is  along  the  lines  of  the  stack  in  Figure  3.  However,  the 
knowledge  base  needs  to  be  developed  for  web  services  that 
communicate  the  PHM  analysis  results  throughout  the 
supply  chain.  Thus,  building  a  table  such  as  Table  1  creates 
the  PHM  ontology  for  an  enterprise.  In  the  stack  that  is 
introduced  in  Section  3,  it  is  viewed  that  the  organization  of 
terms  in  Table  1  is  assembled  at  the  enterprise  level  where 
those  terms  have  meaning  across  the  entire  PHM  system 
area  of  operation.  Ontologies  are  discussed  later  on  in 
Section  3.3.2. 


2.8.  JSF  Autonomic  Logistics  Architecture 

The  F-35  has  the  most  recent  and  complete  PHM  system  for 
a  complex  operating  environment,  having  to  monitor  the  F- 
35  and  its  FI 35  engine.  The  system  detects  faults  and 
predicts  component  lifetimes,  the  results  of  which  are 
transmitted  to  the  maintenance  activities  on  the  ground 
where  aircraft  components  can  be  managed  autonomously. 
That  is,  some  maintenance  activities  are  replaced  by  the 
PHM  results. 

The  development  of  prognostic  functions  is  ongoing,  but  the 
supply  chain  is  able  to  respond  more  quickly  to  aircraft 
maintenance  needs  than  was  previously  possible  (McCollom 
&  Brown,  2011).  There  is  a  concept  of  operations  for 
delivering  analyzed  data  autonomously  from  the  aircraft  to 
the  supply  chain  in  order  to  reduce  supply  chain 
inefficiencies.  There  is  a  stack  of  responsibilities  from  data 
collection  at  the  aircraft  to  the  decision  support  functions  in 
the  supply  chain. 

The  layers  of  the  architecture  are  shown  left  to  right  in 
Figure  8.  Again,  each  of  the  areas  of  responsibility  can  be 
broken  down  into  detailed  stacks  of  functionality.  The  Air 
Vehicle  has  analysis  and  fault  detection  functionality  and  a 
function  that  manages  that  data.  Fault  data  from  the  aircraft 
is  then  reported  directly  to  the  Decision  Support 
Maintenance  Planning  Condition-based  Maintenance  node 
on  the  right,  in  the  spirit  of  the  stack  in  Figure  3. 

The  following  section  suggests  a  structure  that  generalizes 
all  the  architectures  that  were  discussed  in  this  section. 


Air  Vehide 

On  Board  Health  Assessment 


Air  Vehide/Snpport  System 
Interface 
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Off  Board  PHM 
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Decision  Support 
Maintenance  Planning 
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Figure  8.  F-35  Autonomic  logistics  system  deployment 
(McCollom  &  Brown,  2011). 


3.  The  PHM  Reference  Stack 

This  section  synthesizes  the  discussions  of  the  architectures 
in  Section  2  into  a  general  reference  stack  of  PHM 
functions. 
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The  development  of  PHM  architecture  is  based  on 
requirements  for  integrating  PHM  into  the  supply  chain. 
The  requirements  are  generated  by  a  business  case  analysis 
(BCA)  that  justifies  the  cost  of  developing  a  PHM  system 
against  the  cost  of  managing  the  traditional  supply  chain  for 
a  particular  system  (Beyer,  Hess  &  Fila,  2001,  OSD(ATL), 
2010). 

From  the  discussion  in  Section  2,  functional  layers  can  be 
identified  that  reflect  the  activities  in  the  various 
architectures  that  meet  some  need  for  PHM  in  a  supply 
chain.  The  stack  in  Figure  9  is  an  architectural  response  to 
the  requirements  for  PHM  and  defines  the  functions  that 
produce  the  required  return-on-investment  (ROI)  or 
increased  availability.  The  BCA-generated  requirements  are 
the  input  on  the  left. 


Specification  Stack  Security  Stack 
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Enterprise 
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Figure  9.  Functional  reference  stack  of  PHM  Services. 

Figure  9  organizes  the  architectural  functions  into  function- 
type  areas  in  the  columns.  In  the  beginning,  a  set  of 
requirements  is  generated  from  a  process  that  builds  a 
business  case  analysis  for  the  system,  shown  in  the  arrow  on 
the  left.  Such  a  process  includes  interaction  with  suppliers, 
integrators  and  the  other  stakeholders  in  the  supply  chain. 
This  process  is  beyond  the  scope  of  this  paper,  but  provides 
the  motivation  and  formal  requirements  for  developing  the 
system  that  delivers  PHM  functionality. 

The  central  area  is  the  Application  Stack  that  delivers  the 
system  functionality.  Other  stacks  support  the  Application 
Stack:  A  communications  structure  is  on  the  left.  The 
Specifications  Stack  provides  technical  requirements  and 
standards  that  are  levied  on  the  system.  The  Security  Stack 
on  the  right  satisfies  the  information  assurance  requirements 
of  confidentiality,  availability,  integrity,  auditing  and  so 
forth. 

In  discussing  the  architecture  in  Figure  9,  it  is  best  to  start  at 
the  top,  because  the  motivation  for  developing  a  PHM 
system  is  to  improve  the  cost  of  managing  the  supply  chain 
that  supports  systems  in  use  by  an  organization.  Every 
logistics  organization  has  Enterprise  Decision  Support 
Services  at  the  top  layer  where  supply  chain  activities 
manage  parts  and  services  for  the  systems  that  an 


organization  deploys.  The  bottom  layers  produce  the 
information  that  enhances  supply  chain  activities. 

The  following  sections  discuss  the  elements  of  the  stack  in 
more  detail. 

3.1.  Enterprise  Decision  Support  Services 

The  decision  support  services  in  the  enterprises  are  the 
ultimate  recipient  of  PHM  data.  As  mentioned  above,  the 
goal  is  to  create  a  greater  efficiency  in  the  supply  chain  that 
improves  its  operating  costs  by  streamlining  the 
management  of  the  systems  that  are  under  its  control. 
Decision  Support  that  consumes  the  products  of  the 
Analysis  Services  that  are  located  beneath  is  shown  at  the 
top  in  Figure  9. 

Following  the  information  flows  from  the  architectures  that 
were  described  in  Section  2,  Figure  10  abstracts  the  flow  of 
the  PHM  analysis  products  to  the  Supply  Chain  Customers 
that  are  in  the  upper  right  who  receive  analysis  results  from 
the  PHM  functions  that  are  in  the  bounded  region. 

The  Data  Collection  Services  in  Figure  9  can  produce  a 
large  amount  of  data,  such  as  time-series  data,  to  be 
analyzed.  The  analysis  results  are  greatly  distilled  from  the 
raw,  parametric,  data  that  is  produced  by  the  Data 
Collection  Platforms  that  are  shown  on  the  platforms  within 
the  bounded  region  in  Figure  10.  For  Data  Collection- 
Platform  1,  mid-left  in  Figure  10,  the  analysis  function  is 
actually  on  the  platform  and  analysis  results  are  pushed  up 
into  the  enterprise,  as  in  Figure  4  above. 

It  is  important  to  note  that  Figure  9  is  a  logical  structure;  the 
functions  are  logical  and  are  deployed  in  the  implementation 
phase,  thus  can  be  located  where  the  system  design  dictates. 
For  example,  the  architectures  of  Roemer,  et.  al.  (2006)  in 
Figure  4  and  Saha,  et.  al.  in  Figure  5  distribute  Analysis 
Services  to  remote  elements  in  the  design. 


Figure  10.  Injection  of  PHM  analysis  results  from  two 
platforms  into  the  supply  chain. 
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The  analysis  results  that  are  pushed  to  the  supply  chain,  or, 
to  which  the  enterprise  subscribes  in  the  case  of  a  cloud- 
based  Services  Oriented  Architecture  (SOA),  can  have  some 
governed  ontology  that  deals  with  components,  fault  modes 
and  prognostics  such  as  that  described  by  MIMOSA  (2009) 
and  ISO  13374-3:2012  (2012).  Section  2.6  described  a 
semantic  architecture,  and  the  use  of  a  SOA  is  further 
discussed  in  Section  3.3.2. 

MIMOSA  is  a  stack-oriented  data  architecture.  Figure  11 
shows  its  stack  of  functions,  starting  from  a  layer  that  deals 
with  the  acquisition  of  data,  through  layers  that  further 
refine  the  data.  Analysis  occurs  in  the  HA  and  PA  layers, 
the  results  of  which  generate  an  advisory  in  the  AG  layer. 


Advk  ary  Gene  ration  (AG) 


Prognostics  Assessment  (PA) 


Health  Assessment  (HA) 


State  Detection  (SD) 


Dufs  Munipulalion  (DM) 


Data  Acquisition  (DA) 


Figure  11.  OS  A  CBM  functional  blocks  (ISO  13374- 
3:2012). 

Figure  1 1  is  suggestive  of  functions  in  the  PHM  stack  that  is 
shown  in  Figure  9,  and  it  is  used  in  a  data  architecture  that 
defines  the  interfaces  between  these  PHM  functions.  The 
functions  in  in  Figure  9  are  system  functions.  The  data  that 
is  generated  in  its  layers  can  conform  to  the  stack  that  is 
shown  in  Figure  11  but  the  functional  organization  of  a 
PHM  system  is  not  mandated  to  conform  to  the  functional 
organization  that  is  shown  in  Figure  1 1 . 

An  advantage  of  the  ISO  13374  standard  is  that  a  schema 
can  be  built  from  its  data  stack.  This  is  described  in  Section 
3.3.1  for  tagging  the  data  and  in  Section  3.3.2  for 
developing  an  ontology  for  PHM  web  services. 


Figure  10  indicates  that  there  might  be  some  sort  of  service- 
level  agreement  (SLA)  between  the  supply  chain  decision 
support  and  the  analysis  services  and  governance  over  the 
analysis  results  that  are  created  and  its  users  if  data  is  shared 
over  a  SOA.  There  is  a  cost  to  providing  the  SOA  transport. 
Design  costs  as  well  as  operating  expenses  of  the  SOA  need 
to  be  factored  into  the  BCA.  The  SLA  includes 
requirements  for  quality  of  service  (QOS)  which  involves 
the  required  bandwidth  for  data  transfer.  In  Figure  4  above, 
a  data  pipe  is  inserted  for  a  higher  level  of  performance  for 
more  massive  data  amounts  such  as  time-series  data. 
Section  3.3.1  discusses  the  QOS  requirement  for  raw  data 
transport. 

There  is  a  central  notion  to  this  paper  that  the  creation  of  a 
PHM  system  should  not  require  the  refactoring  of  supply 
chain  functions  in  a  dramatic  way,  as  this  would  lead  to 
additional  cost.  Most  supply  chains  today  operate  within 
some  sort  of  enterprise  resource  planning  framework  that  is 
connected  via  a  SOA.  Thus,  it  is  convenient  to  publish  the 
PHM  analysis  results  without  having  to  retool  the  data 
transport  mechanism.  Section  3.3.2  discusses  the  SOA  in 
stack. 

The  functions  in  Figure  9  and  Figure  10  are  to  be  used  in  the 
complete  deployment  of  PHM  technology  to  the  platform 
and  can  used  in  a  BCA  to  develop  the  cost  basis  for  the 
PHM  system  (Sandborn  &  Wilkinson,  2007,  and  Kent  & 
Murphy,  2000) ). 

3.2.  Analysis  Services 

The  Analysis  services  process  the  raw,  parametric,  data 
received  from  the  Data  Collection  layer  that  collects  data 
from  the  critical  components  that  were  identified  in  the 
BCA  and  provide  supply  chain  decision  support  for  life 
cycle  management  of  components.  The  following  two 
sections  discuss  these  modes  of  analysis. 

Analysis  activities  can  be  broken  out  into  a  stack  of 
functions  once  the  target  components  are  identified.  A  good 
discussion  of  the  analysis  process  is  given  by  Roemer,  et.  al. 
(2006)  and  there  are  numerous  approaches. 

3.2.1.  Parametric  Data  Analysis 

The  result  of  the  analysis  process  in  PHM  is  generally  some 
sort  of  estimation  of  remaining  useful  life  of  the  components 
from  a  trend  in  the  data  that  indicates  the  future  behavior  of 
the  component.  The  well-known  idea  is  to  predict  a 
remaining  useful  life  of  a  component,  among  other  analysis 
products,  that  is  injected  into  Supply  Chain  Decision 
Support  to  expedite  its  product  stockage  and  provisioning 
functions,  as  is  shown  in  Figure  10. 

The  notion  really  is  that  there  is  some  stochastic  process  in 
state  space  which  is  therefore  non-deterministic,  but  were 
the  process  known,  would  show  a  path  to  failure  where  the 
operation  of  a  component  passes  into  a  region  of 
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inoperability.  The  time  from  the  detection  of  this  path,  tc , 
say,  to  the  time  of  failure,  fy,  is  the  component’s  remaining 
useful  life  or  RUL.  Figure  12  illustrates  the  path  in  state 
space  of  some  measured  parameters  from  a  component. 
Multiple  parameters  are  more  difficult  to  correlate,  so 
generally,  papers  on  RUL  deal  with  only  one  parameter. 
Figure  12  reminds  us  of  the  underlying  physical 
complexities  of  the  problem  by  plotting  a  multi-dimensional 
state  space. 

The  broadened  paths  indicate  that  the  parameters  are  really 
described  by  a  probability  density  function  with  some 
statistical  moment,  such  as  average,  indicated  by  the  narrow 
path  curve.  Thus,  the  remaining  useful  life  calculation  is 
some  probability  distribution  function.  Examples  of 
stochastic  treatments  of  RUL  are  in  Saha,  Goebel,  Poll  and 
Christophersen  (2007),  Tang,  Kacprzynski,  Goebel  and 
Vachtsevanos  (2009)  and  Sankararaman  and  Goebel  (2013). 

If  we  knew  the  entire  path  for  all  time,  we  would  see  that 
somewhere  along  the  permissible  operating  range  the  path 
bifurcates  into  a  course  that  leads  it  to  failure  at  some  point 
in  the  future.  In  Figure  12  that  point  is  the  red  statistical 
ball,  the  “failure  occurrence  volume”,  where  the  failure 
curve  penetrates  the  operating  volume  at  time  if. 


Figure  12.  Paths,  operating  and  failure,  of  measured 
component  parameters  in  phase  space. 

The  program  in  PHM  is  to  recognize  that  the  system  is 
operating  on  this  failure  path  soon  enough  to  get  the 
information  back  into  Supply  Chain  Decision  Support  so 
that  it  has  time  to  provision  stockage  and  provide 
maintenance  and  part  management  functions  before  the 
actual  failure,  as  is  well  known.  In  Figure  12  the  time  tc  is 
the  time  before  the  failure  time  tf  that  the  prediction  of 
failure  occurs,  and  the  knowledge  of  which  enables  the 
supply  chain  to  act  on  the  predicted  failure  cost-effectively. 

Analysis  services  that  produce  prediction  of  failure,  or 
remaining  useful  life  incur  cost  in  the  BCA.  There  is  an 
open  ended-ness  to  the  analysis  process  because  new  failure 
modes  or  behavior  characteristics  can  be  discovered  by 
continued  analysis,  but  this  is  difficult  to  budget  in  a  BCA. 


The  identification  of  specific  analysis  algorithms  that  are 
attached  to  specific  failures  enables  a  turn-key  system. 
Such  algorithms  would  be  deployed  in  distributed  systems 
such  as  that  is  shown  in  Figure  4  and  Figure  10  where 
analysis  is  distributed  to  the  sensor  locations.  It  may  be 
necessary  to  update  the  remote  CEs  in  Figure  4  with  new 
algorithms  (updating  algorithms  in  regards  to  the  stack  in 
Figure  9  is  discussed  in  Section  3.6).  The  identified  analysis 
algorithms  could  conform  to  standard  measures  that  are 
implemented  in  libraries  in  analysis  tools.  Standards  are 
discussed  more  in  Section  3.5. 

In  regards  to  the  stack  in  Figure  9,  the  interfaces  to  the 
Analysis  layer  need  to  be  defined  so  that  they  are  useful  to 
the  subscribers  in  the  Enterprise  Decision  Support  Services 
above.  Clearly,  the  schematic  analysis  result  in  Figure  12  is 
opaque  to  the  enterprise  that  is  looking  for  extracted 
information  from  it  such  as  RUL.  The  RUL  is  to  be  injected 
into  the  level  of  analysis  that  is  at  the  enterprise  that  requires 
a  greatly  reduced  and  far  more  descriptive  set  of  data  than  is 
raw  data.  Section  3.6  discusses  these  analysis  results  in 
relation  to  the  orthogonality  of  the  functional  layers  in  the 
stack  and  the  next  section  discusses  analysis  at  the 
enterprise. 

Another  aspect  of  Analysis  Services  is  identifying  an 
approach  to  the  analysis.  As  was  mentioned  in  Section  2, 
analysis  methodologies  involve  data-driven  and/or  model 
driven  analysis  processes  (Bernstein,  Hauske  &  Hermann, 
2014,  Byington,  Roemer  &  Galie,  2002).  In  including  the 
analysis  strategy  in  the  Analysis  Services  in  Figure  9,  it 
should  be  understood  that  the  analysis  methodology  can 
impact  the  supply  chain  and  the  BCA  because  there  can  be 
added  cost  to  developing  a  dynamical  physical  behavioral 
model  for  a  component  which  is  a  requirement  of  the  model 
driven  approach. 

Detecting  the  data  signature  of  a  failure  mode  and 
associating  it  with  a  component  is  generally  done  with  a 
model  because  it  is  difficult  to  run  a  statistically  significant 
number  of  components  to  produce  a  failure  signature  for  the 
data-driven  approach  and  run  the  components  to  failure. 
Therefore,  a  model  can  simulate  the  data  that  is  produced  by 
deployed  sensors  and  trace  it  to  a  fault  condition. 

However,  the  data-driven  approach  can  also  incur  inordinate 
costs  if  a  seeded-fault  approach  (Hess,  A.  (2002))  is  used  to 
identify  failure  signatures  because  system  run  time  is 
required  to  associate  the  faults  with  data  signatures.  A 
problem  with  data-driven  analysis  is  the  uncertainty  of 
achieving  a  logical  connection  between  the  analysis  results 
and  the  physics  at  the  data  collection  point. 

In  reality,  there  is  a  model  that  is  developed  from  behavioral 
equations  that  describe  the  physical  behavior  that  produces 
the  sensor  data.  This  is  a  complex,  boundary  value  problem 
to  develop  and  solve.  Therefore,  a  data-driven  approach 
appears  attractive,  but  the  sensors  were  applied  to  the 


458 


Annual  Conference  of  the  Prognostics  and  Health  Management  Society  2014 


critical  component  with  some  understanding  of  the 
underlying  physical  behavior  of  the  system  which  causes  the 
component  to  fault.  To  resolve  these  issues,  the  discussion 
of  how  the  analysis  process  of  a  proposed  PHM  system 
affects  the  BCA  for  the  system  needs  to  occur  with  the 
engineering  community  as  well  as  supply  chain  managers. 

3.2.2.  Supply  Chain  Decision  Support  Analysis 

In  Supply  Chain  Decision  Support  Services  (DSS),  another 
level  of  analysis  occurs  to  determine  the  best  plan  of  action 
for  managing  a  component’s  total  life  cycle  given  the  results 
from  the  PHM  analysis  in  the  previous  section,  as  is  shown 
in  Figure  9.  Thus,  in  developing  a  BCA  for  PHM,  the 
Supply  Chain  analysis  activities  need  to  be  taken  into 
account  in  order  to  estimate  the  impact  that  PHM  has  on 
component  life  cycle  management  in  the  supply  chain. 

Such  a  supply  chain  analysis  model  is  done  in  Feldman, 
Jazouli,  and  Sandborn  (2009)  who  consider  the  costs  of 
integrating  PHM  into  the  supply  chain  in  their  stochastic 
model  for  a  Boeing  737  display,  and  Banks  and  Merenich 
(2007)  develop  a  trade-space  tool  that  calculates  the  cost 
benefit  analysis  for  a  PHM  system  for  batteries  in  vehicle 
power  systems. 

Tsoutis  (2003)  simulates  the  effect  of  the  autonomic 
logistics  system  for  the  F-35  that  is  shown  in  Figure  8  on 
supply  chain  management.  He  incorporates  existing 
maintenance  data  for  the  F/A-18E/F  F-414  engine  (F-35 
maintenance  data  was  of  course  not  yet  available).  His 
work  compares  a  baseline  of  the  traditional  logistics  system 
for  the  F-414  engine  with  a  set  of  modified  repair  activities 
that  are  streamlined  by  the  injection  of  prognostic 
information  from  a  PHM  system  in  the  autonomously 
enabled  aircraft  in  Figure  8.  Tsoutis  was  able  to  perform  a 
sensitivity  analysis  of  the  effects  of  increased  component 
(module)  reliability  and  prognostic  accuracy,  among  other 
parameters.  This  type  of  work  enhances  the  development  of 
the  BCA  and  produces  a  clearer  understanding  of  the  effect 
of  introducing  a  new  PHM  system  into  a  supply  chain.  The 
cost  of  restructuring  a  supply  chain  must  be  included  in  the 
BCA,  and  simulation  of  supply  chain  activities  can 
demonstrate  a  cost  benefit  of  the  PHM  system. 

It  is  clear  that  the  Analysis  Services  function  occupies  an 
important  area  for  the  BCA.  The  stack  in  Figure  9  can  be 
used  to  partition  the  types  of  data,  components  and  types  of 
analysis  to  determine  how  much  effort  is  required  to  reach  a 
result  from  the  analysis  function. 

3.3.  Logistics  Data  Transport 

The  transport  mechanisms  for  PHM  data  are  shown  in 
Figure  9  on  the  left  as  the  Communications  Stack  and  below 
the  Analysis  layer  as  Raw  Data  Transport  Services.  Raw 
Data  Transport  Services  provide  primitive  data  (“raw  data” 
or  parametric  data),  principally  sensor  data  that  can  be 
voluminous  due  to  high  sampling  rates,  to  the  services  that 


analyze  and  transform  it.  Discussion  of  their  mechanisms  of 
transport  is  treated  separately  for  this  reason  in  the  next 
section. 

The  general  Communications  Services  provide  higher  level 
communications  functions  such  as  a  web  services  stack  that 
includes  semantic  information  and  can  be  governed  by  an 
ontology.  They  are  discussed  in  Section  3.3.2. 

3.3.1.  Parametric  Data  Transport 

A  central  activity  in  the  BCA  for  PHM  is  generally  based  on 
identifying  high  cost  components  that  are  expensive  to 
manage  (Banks,  Reichard,  Hines  &  Brought,  2008).  Failure 
characteristics  of  these  components  are  identified  through  a 
failure  modes,  effects  and  criticality  analysis  (FMECA)  that 
leads  to  a  root-cause  analysis  of  the  failure.  The  process 
identifies  a  characteristic  of  the  component  that  can  be 
monitored  by  sensing  a  region  on  the  component  that 
produces  data  that  identifies  that  characteristic  (See  also  the 
discussion  in  Section  3.2.1).  The  sensed  data  quantity  can 
be  large  due  to  the  results  and  recommendations  of  the 
FMECA  and  root-cause  analysis.  As  the  stack  in  Figure  9 
and  flow  diagram  in  Figure  10  show,  the  resulting  collected 
data  needs  to  be  transported  to  the  analysis  services  that 
detect  the  failure  characteristics. 

Sensors  generally  sit  on  buses  such  as  the  well-known  SAE 
J1939  and  MIL-STD-1553  buses.  Determination  of  what 
bus  to  use  is  dependent  on  the  particular  connectivity  with 
the  sensor.  The  Data  Collection  Services  in  Figure  9  define 
the  data  collection  protocols.  The  cost  for  PHM  systems  on 
new  equipment  or  retrofits  includes  the  technology  in  this 
layer.  These  standards  would  be  included  in  the  standards 
in  the  specification  stack,  Section  3.5 

The  communications  protocols  for  raw,  parametric,  data 
need  to  provide  enough  quality  of  service  (QOS)  to  support 
large  data  streams.  The  protocol  for  transporting  the  data 
might  not  be  the  internet,  but  some  physical  mechanism 
such  as  a  local  lap  top  computer  or  portable  maintenance 
aid.  This  configuration  eliminates  the  bandwidth  bottleneck 
but  lessens  real  time  data  collection.  However,  the  Analysis 
Services  could  be  deployed  on  the  local  laptop.  Thus,  the 
stack  in  Figure  9  is  useful  for  partitioning  the  functions  of 
the  PHM  to  the  deployed  areas  in  the  system.  Figure  13 
shows  a  possible  deployment.  QOS  in  regards  to  data 
transport  to  the  enterprise  is  discussed  in  Section  3.1. 

Using  the  Stack  to  Reduce  Bandwidth  Requirements 

Sensor  data  is  generally  a  time  series  that  is  obtained  at 
regular  intervals  at  a  specified  sampling  rate.  The  physics 
of  the  problem  determines  what  rate  is  required  to  discover 
the  data  signature  that  indicates  pending  failure,  as  was 
discussed  in  Section  3.2.1.  As  such,  the  data  can  be  large 
and  hence  require  high  band  widths.  The  cost  of  managing 
big  data  needs  to  be  integrated  into  the  BCA  for  the  PHM 
system.  The  stack  in  Figure  9  is  helpful  because  it  can  be 


459 


Annual  Conference  of  the  Prognostics  and  Health  Management  Society  2014 


used  in  conjunction  with  the  deployment  of  PHM  services  in 
the  supply  chain,  such  as  that  shown  in  Figure  10  and  those 
that  were  discussed  in  Section  2..  A  tradeoff  analysis  of  the 
location  of  Analysis  Services  can  reduce  the  cost  of 
bandwidth.  For  example,  Figure  5  distributes  the  analysis 
function  to  local  computational  elements  that  is  a  measure 
that  greatly  reduces  the  burden  of  having  to  supply  a  high- 
bandwidth  transport  for  sensor  data. 

Describing  or  Tagging  Sensor  Data 

An  ideal  is  to  publish  this  raw  sensor  data  in  the  context  of  a 
services -oriented  architecture.  Sensor  data  can  then  flow  up 
the  left  SO  A  stack  in  Figure  9. 

There  are  formats  that  tag  sensor  data  in  order  to  develop  a 
publish/subscribe  mechanism  at  the  parametric  data  level. 
This  adds  overhead  to  the  sensor  data  but  for  large  data 
transfers  the  headers  are  relatively  small.  One  well  known 
format  is  in  the  NASA  CDF  applications  library  (CDF 
User’s  Guide,  2012).  A  data  tagging  standard  was  built  on 
top  of  that  for  PHM  systems  by  the  US  Army  known  as 
Army  CBM  Bulk  Data  (ABCD)  format  (US  Army  PEWG, 
2011).  The  tagging  in  ABCD  format  respects  the  data 
layers  that  are  found  in  the  MIMOSA  standard  (MIMOSA, 
2009)  and  in  ISO  13374-3:2012  (2012). 

All  these  standardization  activities  need  to  be  included  in 
developing  the  BCA  for  PHM.  The  advantage  is  that 
developed  standards  such  as  NASA  CDF  come  with 
functional  software  applications  programmer  interfaces  that 
eliminate  the  cost  of  new  software  development.  The 
Standards  Stack  in  Figure  9  is  useful  to  organize  the 
standards  at  each  level  of  the  architecture.  Standards  are 
discussed  in  Section  3.5. 

3.3.2.  Communications  Services 

Communications  services  transport  logistics  information 
throughout  the  supply  chain.  The  stack  diagram  in  Figure  9 
and  data  flow  diagram  in  Figure  10  illustrate  that  these  are 
the  communications  services  that  inject  derived  analytical 
information  into  the  supply  chain. 

It  is  also  envisioned  that  there  is  a  Services  Oriented 
Architecture  (SOA)  to  provide  the  transport.  An  enterprise 
service  bus  (ESB)  (Chappell,  2004)  that  provides  connectors 
and  messaging  services  as  well  as  other  functions  in  the 
SOA  stack  enables  the  SOA. 

Enterprise  Services  Bus 

The  services  stack  in  Figure  9  is  meant  to  be  integrated  into 
an  existing  SOA  that  is  provided  by  the  supply  chain  that 
requests  PHM  technology.  Adding  the  additional  cost  of 
developing  a  SOA  to  the  PHM  BCA  would  be  excessively 
costly.  Furthermore,  it  is  a  distinct  advantage  to  be  able  to 
publish  PHM  logistics  data  to  existing  supply  chain  services 
that  already  make  use  of  enterprise  services  technology. 


Web  Services  (SOA) 

Web  services  itself  provide  a  stack  of  functions  (W3C, 
2004),  but  the  configuration  varies  widely  with  providers. 
The  supply  chain  would  have  a  services  architecture  with 
governance  and  provisioning  already  determined.  Thus,  the 
PHM  system  should  be  able  to  publish  the  analysis  results  to 
the  supply  chain  that  subscribes  to  it.  Again,  it  is  meant  to 
require  minimal  effort  to  connect  to  the  supply  chain. 
Section  3.1  discussed  the  role  of  a  SOA  in  communicating 
PHM  analysis  results. 

Figure  13  illustrates  a  possible  deployment  of  a  SOA 
architecture  for  PHM  data  transport  in  a  military 
environment.  Here,  an  ESB  is  located  at  each  of  the  nodes 
in  the  Tactical,  Operational  and  Enterprise  areas  and 
implements  a  SOA  stack.  Data  collection  on  the  Vehicle 
Platform  in  the  tactical  environment  involves  both  the  SOA 
for  analyzed  data,  which  can  be  generated  on-platform,  and 
a  fast  pipe,  such  as  that  in  Figure  4  for  parametric  data 
transport.  There  is  data  analysis  on  platform  as  in  Figure  4 
and  Figure  5.  Raw/Parametric  data  is  transferred  to  the 
operational  node  via  a  maintenance  support  device,  such  as 
a  laptop  or  PDA  over  the  high  bandwidth  link  to  support  the 
bandwidth  requirements.  Decision  support  services  (DSS) 
exist  at  the  Enterprise  node  where  the  analysis  is  the 
decision  support  analysis  that  is  discussed  in  Section  3.2.2 
for  lifecycle  support.  Note  that  the  functions  in  the  stack  in 
Figure  9  are  deployed  in  Figure  13  and  the  deployment 
looks  like  that  in  Figure  10. 

The  SOA  makes  the  sharing  of  data  seamless,  but  the 
diagram  indicates  that  there  has  to  be  a  common 
understanding  of  terminology  of  data  types  in  the  supply 
chain.  In  this  environment,  the  ISO  13374  tagging  (See 
Section  3.3.1)  is  useful  for  sharing  the  raw,  parametric,  data. 

The  ontology  produces  a  common  knowledge  base 
throughout  the  supply  chain  and  between  enterprise 
domains;  the  ontology  can  be  used  to  communicate 
diagnostic,  health  and  prognostic  information  from  one 
logistics  domain  to  the  next.  The  data  schema,  such  as 
parametric  data  from  the  Tactical  node  in  Figure  13,  is 
governed  by  the  MIMOSA  standard  (MIMOSA,  2009)  as 
shown  in  Figure  14.  The  enterprise  is  the  locus  of  domain 
expertise  and  has  a  domain-specific  ontology  that  is 
developed  by  stakeholders. 
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Figure  13.  Notional  deployment  of  a  PHM  system 
incorporating  a  SO  A  with  corresponding  ESB. 

The  organization  might  further  develop  an  ontology  to 
enable  semantic  structure  to  the  data  (W3C  Semantic  Web, 
2014).  An  ontology  is  developed  by  Emmanouilidis,  et.  al., 
(2010)  which  was  shown  in  Section2.6;  the  domain 
structure  is  shown  in  Figure  14.  It  is  at  this  point  that  a 
table  such  as  Table  1  can  be  developed  at  the  enterprise  to 
identify  the  semantic  elements  in  the  PHM  system  that  is  to 
be  designed. 


Figure  14.  Diagnostic  ontology  of  Emmanouilidis,  et.  al., 
(2010). 


Including  the  cost  and  effort  of  developing  a  PHM  system 
ontology  in  a  BCA  is  a  complex  task.  It  is  of  course  better 
to  incorporate  existing  ontologies  such  as  MIMOSA  and  the 
data  stack  that  is  described  by  ISO  13374.  In  developing  a 
domain-specific  ontology,  the  BCA  should  investigate 
existing  ontologies  in  the  organization  and  look  to  expand 
them  with  PHM  terminology.  Barring  that,  the  effort  needs 
to  be  closely  monitored  and  costs  need  to  be  estimated  as 
early  on  as  possible.  Ontologies  are  best  restricted  to 
systems  of  common  functionality  in  order  to  bound  the 
effort. 

3.4.  Security  Stack 

The  architectures  that  are  discussed  in  Section  2  are  shy  of 
data  security  measures,  in  part  because  PHM  is  the  central 
function  of  the  architectures  and  in  part,  because  the  data  is 
not  mission-critical  data.  For  example,  on  an  aircraft  there 
is  system  control  data,  which  is  of  course  critical,  while 


PHM  data  is  produced  in  order  to  monitor  the  operation  of 
the  controlled  system. 

Data  streams  of  time-series  data  such  as  that  shown  by  the 
data  pipe  in  Figure  4  can  be  protected  by  link  encryption 
while  services  that  produce  higher  level  semantically 
governed  information  can  be  protected  by  implementing 
standards  such  as  WS-Security  (OASIS,  2004). 

The  stack  on  the  right  in  Figure  9  addresses  the  security  for 
the  layers  in  the  Applications  Stack.  What  would  be  filled 
in  here  for  the  implementation  are  the  specified  security 
standards  that  are  going  to  be  used  to  provide  information 
assurance  to  the  stack.  In  developing  the  BCA  for  the 
particular  PHM  system  that  is  under  consideration,  the  cost 
of  security  may  be  relevant. 

In  developing  PHM  for  military  systems  (Butcher,  2000), 
there  are  well-defined  directives  and  procedures  that  need  to 
be  followed,  indeed,  required  to  be  followed,  such  as  Net 
Ready  Key  Performance  Parameter,  (NR  KPP)CJCSI6212, 
2012)  and  Information  Assurance  Certification  and 
Accreditation  Process  (DIACAP),  (DoDI  8510.01,  2007). 
The  implementation  of  DIACAP  requirements  requires 
additional  time  and  obtaining  a  formal  authorization  to 
operate  the  system. 

Collocating  PHM  data  services  with  secure  areas  could 
incur  a  cost,  possibly  a  cross-domain  solution  that  would 
have  another  form  of  certification  (DISN,  2004).  The  stack 
in  Figure  9  is  useful  for  identifying  where  data  is  produced 
in  order  to  identify  the  security  boundary  of  the  originating 
systems  (NIST  800-18,  2006),  a  primary  task  in  information 
assurance. 

3.5.  Specification  Stack 

As  mentioned  at  the  end  of  Section  3.3.1  that  discusses 
tagging  sensor  data  by  using  specifications  for  various  PHM 
functions,  the  stack  in  Figure  9  organizes  standards  and 
exposes  them  to  the  developer  community  for  evaluation  of 
their  effectiveness.  In  Figure  9,  the  Specification  Stack  is  to 
be  augmented  with  the  specifications  that  the  design 
incorporates. 

The  specification  stack  begins  at  the  top  where  decision 
support  activities  occur  to  support  lifecycle  systems 
management.  These  standards  will  already  be  in  place,  as 
PHM  architecture  does  not  refactor  the  supply  chain 
architecture;  it  would  be  difficult  to  justify  a  cost  for  doing 
so.  However,  the  JSF  autonomic  logistics  architecture  in 
Section  2.6  does  affect  some  of  the  organizational  structure 
of  maintenance  because  its  autonomic  prognostic 
notification  of  faulty  parts  on  the  aircraft  can  remove  a 
maintenance  inspection  step.  A  discussion  of  a  simulation 
of  this  effect  was  given  in  Section  3.2.2. 

The  employment  of  standards  can  affect  the  BCA  for  the 
PHM  system;  the  decomposition  in  Figure  9  can  be  factored 
according  to  the  envisioned  and  simulated  cost  model  for 
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the  PHM  system.  The  use  of  standards  over  custom 
specifications  more  confidently  reduces  the  cost  of  the  PHM 
system.  An  example  is  the  use  of  standard  analytical 
methods  for  analyzing  sensor  data  (See  Section  3.2).  While 
a  lot  of  analysis  work  is  specific  to  a  particular  system,  the 
BCA  can  require  that  standard  analysis  libraries  and  tools  be 
employed  to  conduct  the  search  for  failure  precursors  in  the 
sensor  data. 

3.6.  Orthogonal  Property  of  the  Stack  Layers 

As  discussed  in  the  Introduction,  the  functions  in  the  layers 
in  Figure  9  are  isolated  from  adjacent  layers.  In  good 
systems  architecture,  each  layer  contracts  with  the  services 
from  the  layer  below  it  via  a  well-defined  interface  and  has 
no  knowledge  the  internal  functionality  of  its  neighbors. 
Services  do  not  get  data  from  the  service  layers  above  them. 
One  could  ask  if  a  lower  layer  receives  data  from  a  higher 
layer  in  the  case  of  Figure  5,  where  new  analysis  algorithms 
are  distributed  to  the  remote  CEs  (this  update  process  was 
mentioned  in  Section  3.2.1).  However,  this  would  be  a 
transaction  within  the  analysis  layer  in  the  stack  in  Figure  9 
and  would  not  violate  the  read-down-only  principle.  Recall, 
the  stack  in  Figure  9  is  not  a  deployment  diagram  that 
specifies  where  services  physically  reside. 

An  example  of  functional  separation  between  layers  is  the 
analysis  layer:  the  Supply  Chain  Decision  Support  Analysis 
Services  and  the  Parametric  Data  Analysis  Services  layers 
in  Figure  9.  Supply  Chain  Decision  Support  Analysis 
Services  would  have  no  access  to  the  raw,  parametric  data 
from  the  Parametric  Data  Analysis  Services  below  it. 
Instead  it  subscribes  to  an  agreed-upon  analysis  result, 
possibly  component  RUL,  through  a  contractual  interface.  It 
does  not  have  the  same  analysis  functions  or  purposes  of 
analysis  as  are  in  the  Parametric  Data  Analysis  Services 
layer.  In  terms  of  a  BCA,  this  means  that  there  is  no 
duplication  of  effort  between  the  layers  and  there  is  no 
confusion  of  functions  in  the  layers.  The  argument  is  the 
same  for  all  other  layers. 

4.  Conclusion 

Figure  9  presented  a  reference  stack  of  functional  areas  that 
would  comprise  a  reference  architecture  for  a  PHM  system. 
Its  development  was  motivated  by  the  analysis  of  several 
existing  PHM  architectures  in  Section  2.  Closely  attached 
to  this  stack  is  the  business  case  analysis  (BCA)  that 
provides  a  motivation  for  developing  a  PHM  architecture. 
The  reference  stack  in  Figure  9  supports  the  BCA  by 
making  the  functional  composition  of  the  proposed  PHM 
system  transparent  to  the  cost  and  availability  requirements 
that  are  generated  by  the  BCA. 

Included  in  the  stack  in  Figure  9  are  additional  stacks  that 
track  the  specifications  to  which  the  PHM  system  is 
designed.  They  are  constraints  on  the  cost  of  the  system. 
Choosing  existing  specifications  of  services  can  reduce  the 
cost  of  the  system.  On  the  other  hand,  security  requirements 


can  be  a  burden  on  the  cost  and  availability  of  a  PHM 
system.  The  communications  stack  describes  the  data 
transport  functions  for  the  PHM  system  but  is  also  meant  to 
identify  open-source  transports  and  a  SO  A  that  can  be 
integrated  easily  into  the  existing  supply  chain  enterprise 
services  structure. 

The  PHM  architectural  reference  stack  is  an  effective  way  to 
communicate  PHM  system  functions  to  the  stakeholders  in 
the  supply  chain  who  have  commissioned  the  PHM  system 
to  reduce  the  lifecycle  costs  of  the  components  that  they 
manage. 
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leads  a  group  that  is  focused  on  the  analysis  of  enhanced 
sensor  data  to  determine  statistically  and  physically  based 
causes  of  component  failure  in  order  to  develop  prognostic 
assessments. 
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